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Abstract — 

When combining data from distinct sources, there is a need 
to share meta-data and other knowledge about various source 
domains. Due to semantic inconsistencies and heterogeneity of 
representations, problems arise in combining multiple domains 
when the domains are merged. The knowledge that is irrelevant 
to the task of interoperation will be included, making the result 
unnecessarily complex. 

This heterogeneity problem can be eliminated by mediating the 
conflicts and managing the intersections of the domains. For in- 
teroperation and intelligent access to heterogeneous information, 
the focus is on the intersection of the knowledge, since intersec- 
tion will define the required articulation rules. 

An algebra over domain has been proposed to use articulation 
rules to support disciplined manipulation of domain knowledge 
resources. The objective of a domain algebra is to provide the 
capability for interrogating many domain knowledge resources, 
which are largely semantically disjoint. The algebra supports for- 
mally the tasks of selecting, combining, extending, specializing, 
and modifying components from a diverse set of domains. 

This paper presents a domain algebra and demonstrates the 
use of articulation rules to link declarative interfaces for Internet 
and enterprise applications. In particular, it discusses the ar- 
ticulation implementation as part of a production system capable 
of operating over the domain described by the IDL (interface 
description language) of objects registered in multiple CORBA 
servers. 
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L Introduction 

Today, designers, developers, and users realize that informa- 
tion in private and public databases, as on the Internet, provides 
increasing opportunities to enhance productivity. Understand- 
ing the content of the available information requires the use of 
domain knowledge. For example; acquiring an air fare from 
a travel agency on the Internet requires an understanding of 
layout (e.g. parsing) of the corresponding HTML pages. Fur- 
thermore, the effective use of the knowledge to support problem 
solving also requires the use of multiple domain resources, for 
instance comparing prices from different agencies to meet a user 
query. 

A number of technologies have been developed to support 
large-scale interoperation among distributed applications [41]. 
However, managing large-scale interoperation of domains re- 
mains a task which requires many levels of expertise and an 
adherence to standards. 

Many existing systems have strong notions of interfaces. Ef- 
forts like extensible Markup Language, the next generation of 
HTML, are only ways to put structure into a web page. These 
interfaces allow the specification of the domain’s knowledge or 
the domain component syntax. Leading efforts in interoperat- 
ing among multiple domains are often implemented as the union 
of multiple domains. An immediate increase in data integration 
is noticeable to data integration architects. Yet, there are con- 
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sequences 1 to the union of multiple domains which turn out 
not to be efficient for the evolving needs of customers, such as 
resource allocation (storage and staffing). Worst, however, the 
union will become impossible to maintain. 

For interoperation and intelligent access to heterogeneous 
information, the focus should be on the intersection of the 
knowledge, since intersection will define the required articu- 
lations. The term articulation refers to the linkages which 
join concepts across domains [15]. The emergent need to 
define articulations between data resources has been demon- 
strated and described in [24][47]. For instance, Yahoo's hierar- 
chal classification and Auto.com, “Yahoo’s category Business- 
and-Economy/ Companies /Automotive” and “Auto.com daily 
reviews” can be well articulated (linked)-. 

We extend and generalize the identification of the articula- 
tion to a set of manipulations, such as selecting, combining, ex- 
tending, specializing, and modifying components from diverse, 
common and domain-specific knowledge. To deal with most of 
these issues, a domain algebra has been proposed in [46] which 
is intended to support disciplined manipulation of knowledge 
resources. The representation of vocabularies and their struc- 
ture is termed domain knowledge whereas the operations that 
combine and partition the domain knowledge in a sound and 
well-behaved manner are termed a domain algebra. The basic 
algebra consists of three operations, namely intersection, union 
and difference (negation is considered an alternate form of the 
difference). Knowledge in this paper is limited to the knowledge 
that an expert can extract from a domain and not the domain 
itself 2 . 

The objective of a domain algebra is to provide the capability 
for interrogating many knowledge resources, which are largely 
semantically disjoint, but where articulations have been estab- 
lished. Articulation rules will enable on their own a new type 
of interoperability from Server-to-Server, 

This paper describes the role of a domain algebra in a medi- 
ated architecture among declarative interfaces. It also demon- 
strates the use of an algebra which provides users and system 
developers with the ability to intelligently manipulate compo- 
nents in real time. 

The idea of combining articulation-rules [37] with declarative 
interfaces is complementary: declarative interfaces are primarily 
about specifying component syntax and distributed implemen- 
tations [39], whereas articulation rules are a promising research 
outcome recycled from Artificial Intelligence and have addressed 
in the past issues of component design, component binding, and 
component semantics. 

A. Background 

An introduction to domain algebra is presented in references 
[46] [47]. In these papers, the advantage of a domain algebra 
is described. Some suggested interoperation functionalities of 
the domain algebra are presented in [28]. Also, there has been 
a significant amount of research in the interoperable systems 
community. The representative literature in semantic interop- 
erations is presented in [41] [13] [12]. Much of this work conforms 
to describing interfaces which mirror the effort in the database 
community [10] [1] that addresses the problem at the schema 
integration level [2 5] [48]. There axe a number of similarities 
with the database and knowledge-base community and the pro- 
posed work: the concept of articulation [15] [24],. translating het- 
erogeneous information into a meta-level model [34] [45], active 

l Also down-loading Internet classifications are copyright infringement by U.S. 

Law. 

2 e.g complete schema dump. 
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database [43] and associating constraints and triggers with ob- 
jects [17]. This paper focuses on the adaptation of methods 
from the heterogeneous database literature, mediation and in- 
tegration aspects to the problem of disciplined manipulation of 
information sources across networks, languages and platforms 
(e.g. HTML, XML, CORBA etc.). 

B. Object Oriented Bindings 

Many existing systems have strong notions of interfaces. 
These interfaces allow binding to services provided by their cor- 
responding architectures if their interfaces are described. New 
standard efforts like extensible Markup Language allow a Doc- 
ument Type Definition (DTD) where grammars and structures 
of the markup language are defined [49]. 

Systems like Object Request Broker (ORB) [38] and Inter! 
Language Unification (ILU)[I6J promote interoperability via in- 
terfaces between domains. Domains are known by their inter- 
faces and became an industry standard with the Common Ob- 
ject Request Broker Architecture (CORBA) often known as The 
CORBA Standard . In an object-oriented approach, a domain’s 
interface is bound to the system’s object-oriented interface defi- 
nitions language. This paper will illustrate the implementation 
of an ORB-to-ORB interopertion and hence demonstrate a new 
and modern approach to interoperability from Server-to- Server 

C. A modem Approach : Server-to- Server 

Considering that declarative interfaces are primarily about 
specifying syntax and component implementation, it appears 
that our approach complements the concept of declarative in- 
terfaces for interop erabilty problems (e.g. interoperability as- 
pects in XML and CORBA). There are two mam differences 
with, the current technology: we support (i) } the heterogeneity of 
the interfaces , and (iij the autonomy of the interfaces. The first 
problem relates to the problem of semantic mismatch and granu- 
larity incompatibility. The second problem is that interfaces are 
defined by resources available at a compile time and hence they 
may not fully cooperate in runtime (e.g a web page update), 
some issues similar to these problems have been discussed with 
respect to the modern concept of coordinating distributed ob- 
jects in declarative interfaces as in [21][36]. 

The problem of interoperation among heterogeneous systems 
is central to the area of integration, as represented in [50]. 

The proposed modem approach of Server-to-Server has been 
adopted by Science Gate Bay [42] and has been extended to sup- 
port information integration on the Internet with XML. Some of 
the work has appeared in parts under [28], [27]. Some early im- 
plementation aspects have appeared as a public software release 
[29]. 

II. Knowledge Representations and Interoperation 

The development of the mediation model reported in this pa- 
per is motivated by the need of interoperability among exist- 
ing domain-specific representation of knowledge (structure and 
layout) and their respected formalisms (HTML, XML, Objects 
etc.). 

Although the spirit of this paper is to underline practical 
aspects recycled from Artificial Intelligence with an objective of 
matching industry current needs, what follows is a brief review 
of what is commonly known in the Knowledge Representation 
ajid Artificial Intelligence co mmun ity. 

The series of knowledge representation formalisms and frame- 
works starting with KL-One [7] and currently cu lm inating in 

3 compare to client-server 


systems like Classic [5] and LOOM [35] provide powerful tools 
and knowledge expressiveness. However, they were not intended 
to interoperate. How much has to be added to their infrastruc- 
ture and reasoning capability to achieve knowledge interoper- 
ability is still unclear. 

While knowledge representation is thought of as being a way 
to resolve integration problems, most knowledge representation 
formalisms have focused on paradigms which assume an inte- 
grated environment and have been careless about managing the 
exceptions. In our approach, we focus on these exceptions. 

Prom a research and technical point of view, there have been 
two recent efforts that open up possibilities for meaningful 
knowledge interoperation: the development of context logic [31] 
and knowledge interfaces for sharing [37]. The advance in con! 
text logic is the notion of translating encoded knowledge relative 
to its context and hence relates the knowledge to its domain. 
This is the approach taken in the re-engineering of Cyc [30] 
where micro-theories confine the Contextual differences [24]. Ad- 
vances in knowledge sharing revolve around translating multiple 
knowledge, from one formalism, to multiple formalisms. How- 
ever, the problem of translating many domains into different 
representations will create several problems. Semantic incon- 
sistencies will arise from the terms and relationships used from 
the merged domains. Additional inconsistencies occur when 
the knowledge-content differs both in semantics and in compo- 
sitional granularity. In addition, the union of multiple domain 
knowledge includes irrelevant knowledge and the result will be 
large, unorganized, and disproportionally costly to process. 

An early formal paradigm in the direction of porting knowl- 
edge from one representation language into multiple ones was 
done by Ontolingua [23]. Ontolingua is a mechanism for trans- 
lating from a standard syntax into multiple-representation sys- 
tems. However, directly translating entire knowledge to any 
arbitrary representation leads to irrelevant knowledge and se- 
mantic inconsistencies, disproportioned in content. 

Interoperation became an industry fact with CORBA. 
CORBA is a system of standards and specifications that de- 
scribes how software components, as being the domain knowl- 
edge, can interoperate across networks, languages and plat- 
forms. CORBA allows for client-server interaction between 
heterogeneous objects distributed over a wide-area network. 
CORBA makes meta information describing the objects in a 
system and their interfaces available so that it can access other 
objects. Any object connected to an Object Request Broker 
(ORB) can play simultaneously the role of client and server and 
hence Objects can initiate calls and respond to requests. ORB 
is the part of CORBA which facilitates client-server communi- 
cation and interaction between distributed objects. To reach 
object interoperability and for objects to plug and play, clients 
have to know exactly what they can expect from every object 
they might call upon for a service. 

With the success of Hypertext Markup Language (HTML) 
and large-scale content distribution of heterogeneous informa- 
tion, industry pushed the technology further with the extensi- 
ble Markup Language (XML). XML was primarily intended to 
meet the requirements of large-scale Web content providers for 
industry-specific markup, vendor-neutral data exchange, one- 
on-one marketing, workflow management, the processing of Web 
documents by intelligent clients , and most meta-data applica- 
tions. 

A. Engineering a Functional Model 

Information integration for Internet and enterprise applica- 
tion is a relatively new but growing area of concern, moving 
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well beyond objects, Hypertext and the sharing of documents. 
Software and data provide the capability for active sharing of 
concepts and many other tasks beyond the ubiquitous and over- 
loaded information world. The Internet proved to be practical 
and functional fact and deserves to be looked at pragmatically. 
Even though this paper is driven by a long-range vision, the 
proposed engineering methodologies allow a continuous stream 
of early experiments and development. Such an approach is an 
attractive alternative to the more philosophical approach, which 
assumes that all fundamental issues have been solved first. 

In this paper, we plan to manipulate information labeled with 
the domain context where context will encapsulate the mean- 
ing-. Another objective of this paper is to support knowledge ab- 
straction between different knowledge compositions. Abstrac- 
tion with context will hence play an essential role in the algebra 
since different domain compositions have different context gran- 
ularities. It is yet another objective of this paper to delineate 
the extent of domain knowledge into partitions. But the main 
objective of this paper is to assert articulation rules which link 
domain knowledge. Hence, the planned domain algebra should 
bring about better knowledge scalability. 

The process of abstraction separates the domain from its im- 
plementation. For instance in articulating Yahoo’s category 
“Business-and-Economy /Companies/ Auto motive” , 

“ Auto. com” would not require the inherented hierarchy (i.e. 
/Business-and-Economy/Companies/). The notion of separa- 
tion was initially suggested in the scheme of the Agent Commu- 
nication Language [21]. We realize that there is much leverage 
in articulating the domains in the mediation level within par- 
titions because that is where the abstraction is best reasoned 
about and understood. 

When designing a domain algebra for diverse domains, it is 
important to understand the constraints that the articulation 
rules set over the underlying knowledge. Articulating a domain 
at multiple levels increases the domain scope when compared 
to the articulation rules set only at the atomic knowledge in 
the domain. This is the case when respectively articulating 
tables and attributes in relational databases and articulating 
only the attributes. Writing articulation rules requires a good 
understanding of the domain as well as an established expertise. 

Our hypothesis is that a domain algebra is feasible within 
a mediated architecture. Furthermore, when the articulation 
rules establish a rule-based environment, we sustain the oper- 
ations needed by the algebra. The mediator will seamlessly 
re-partition and re-combine articulation rules. 

B. Mediation 

A mediated model scales and partitions domain knowledge us- 
ing the articulated knowledge rather than the domain knowledge 
itself. Every integration goal requires new objective domain ex- 
pertise to hand-craft or statistically learn (e.g. data mining) 

[8] [3] [26] the necessary articulation rules. In a practical sense 
there is no magic in current leading Intenet technology such as 
“NetNanny” [33] or “Alexa” [4] where both technologies directly 
articulate the Internet based on IP numbers 4 . 

While an information mediation admits formal definitions in 
the literature, mediation obeys strong engineering practices. To 
build a functional application, the focus should be on the inter- 
section of the knowledge among the domains since intersection 
will define the required articulation rules. Articulating domains 

4 u Alexa" establishes mappings on IP addresses and display the mappings when 
an IP is selected. While "Alexa" *s rules are statically learned, “NetNanny”’s 
rules are hand-crafted into a boolean type block/allow. 


introduces a radical change in the definition of the domain ex- 
pert. 

An additional new role while articulating domain knowl- 
edge for the domain expert is the partitioning of the artic- 
ulations . Partitioning separates the articulation rules into 

partitions or bundles (modules). For example the artic- 
ulations between domains “Yahoo’s category Business-and- 
Economy/ Companies/Automotive” and “auto.com” reside in 
one partition whereas the articulations between “auto.com” and 
“General Motors (gm.com)” reside in another partition. Prac- 
tically one may be better off with additional partitions for each 
pair of knowledge sources to enhance potential sharing (e.g. 
generic rules like lower /upper case mapping conventions). 

It is clear in this model that partitions and contexts are dis- 
tinct. Partitions are regarded as a “bundle” of articulation rules 
among domains. On the other hand, contexts establish the la- 
bels over the domain knowledge. Since partitions are more likely 
to be encapsulated, redundancy in the domain knowledge and 
contexts occurs when domains tend to be homogeneous. The 
formulated articulation rules are used for linkages across do- 
mains will also exhibit redundancy, for instance, articulating 
pairwise airline companies with airline companies. However, 
what would be preferred and more meaningful would be to ar- 
ticulate pairwise airline companies with travel agencies. With a 
little care and hand-crafting of the partitions, redundant artic- 
ulation would be shared by sharing the appropriate partitions 
(e.g. word stemming, names mapping, special parsing etc.). In 
general our approach will scale much better in heterogeneous 
domains. 

C. Declarative Interfaces 

In this section we illustrate an example of a domain knowledge 
written in CORBA’s specific Interface Definition Language [38]. 
The same example will be used in the implementation section 
to demonstrate the interoperability. 

To reach object interoperability and for objects to plug and 
play, clients have to know exactly what they can expect from 
every object they might call upon for a service. In CORBA, 
the services that an object provides are described to interface 
between the object itself and the rest of the system. The ob- 
jective of the interface is twofold: (i) it informs clients of the 
services that the objects provide as well as the access method 
to invoke these services and (ii) it informs the communications 
infrastructure of the format and syntax of the access methods. 

CORBA Interface Definition Language (IDL) is defined as a 
language for describing the interfaces of software objects. An 
interface is a description of the set of possible operations that 
a client may request of an object [38]. An IDL interface specifi- 
cation contains declarations of types, exceptions and constants. 

As most declarative interfaces, EDL is independent of program- 
ming languages, and is used to describe objects implemented. 
For instance, the IDL specification of an object Bicycle and 
5 s Shop can be described as follows: 

interface Shop { 

readonly attribute long parent; 
void setfint long value); 
long get(); 

>; 

interface Bicycle : Shop { 

readonly attribute short size; 
readonly attribute short color; 
short getSizeQ; 
short getColorO; 

>; 
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The information represented by the IDL specification for any 
objects connected to a CORBA server is compiled and stored in 
the Interfact Repository service which the server provides. The 
interface repository can be examined by objects on the server 


Abstraction: Abstraction is equivalent to the production of 


in order to ascertain what other objects are connected to the 
server and what interfaces they provide. This allows an object 
to request services from other objects on the server without 
having prior knowledge of the other objects or their interfaces. 

III. Terminology, Definitions and Assumptions 

The domain algebra scales partitioned domain knowledge by 
operating over the articulation rules . The partitioning of a do- 
main iCnoWicuge IS vudunuy uciticu uy ji’iTSu Oidcl TogiC (FOLi) 
formalism since the first order logic is explicitly treating the 
articulation rules themselves. This traces back early work on 
algebras [14] which were demonstrated by first order predicate 
calculus. 

Exporting data independently of the specific implementation 
defines the interoperability capability of a domain. The domain 
knowledge that describes the data has no representation and is 
only defined by the terms and relationships. For example, data 
could reflect the price of a component whereas the knowledge 
is the name of the component. This decomposition of a domain 
to its knowledge enables pattern matching over the terms and 
relationships. 

In this paper, we also address the problem of how to abstract 
and encapsulate encoded knowledge within contexts. Knowl- 
edge abstraction as used in this paper composes declarative 
knowledge compositions, keeping their context through formal 
predication. We also address the foundation of context formu- 
lation as a basic and simple problem in propositional calculus. 
Establishing context is also a novelty of this paper, and is a topic 
which is poorly discussed in the literature. The abstraction and 
context transformations represent the needed knowledge from 
the domain source model. 

The mediation model produces the environment needed to 
provide users and system developers with the ability of an al- 
gebra to perform the tasks of selecting, combining, extending, 
specializing, and modifying multiple domain-specific knowledge. 
These manipulations will support the interoperation of descrip- 
tions of topics of interest when using the knowledge. These 
descriptions are reusable by multiple applications that need to 
access diverse data sources. The descriptive formalism makes 
the mediated architecture maintainable in rapidly changing en- 
vironments. 

Domain Knowledge: Predicates are the basic construct of 
declarative knowledge. For example, one can express in first 
order logic the fact that a Book is above the Table by tak- 
ing a relation symbol such as Above and defining a predicate 
Above (x,y). Hence, for the object symbols Book and Table we 
can declare the proposition Above (Book, Table) [20]. Often, a 
predicate contains semantic conjunctions or disjunctions within 
its syntax [18] to express complex relation constructs. 

To deal with the inadequacy of semantics and to conform to 
the syntactics of predicate logic, structured predicates are sep- 
arated into simpler atomic propositions. If for example a do- 
main considers the proposition Above(Book and Pen, Table), it 
is equivalent to the conjunction of the following two predicates 
Above (Book, Table) A Above (Pen, Table). In general, pred- 
icates are atomic and do not contain semantic operators. 

Writing the domain knowledge is a task that often is auto- 
mated by wrappers. Either way, expertise is required in writing 
the knowledge directly or formulating the wrapper itself. □ 


simpler approximations of the domain knowledge often driven 
by approximation rules (e.g. stemming rules). When do- 
main knowledge involves a large vocabulary, abstraction is also 
the process of aggregating the domain model to another in- 
volving smaller vocabulary and fewer constant, as in the in- 
stance of using the term “Automotive” instead of “Business- 
and- Economy/ Companies/ Automotive” . Often the aggregation 
is performed by translating the declarative knowledge predicates 
and grouping the vocabulary and constants into arbitrary well- 
formed formulas. In [2], one can distinguish the different types 
of abstraction such as qualitative abstraction, quantitative ab- 
straction. terminological abstraction and temporal abstraction. 
In our work, however, the notion of abstraction focuses on ma- 
nipulating knowledge within context. 

For example, in the case of applying the relation sym- 
bol Above to the objects Book and Table and a third argu- 
ment denoting a situation s, say {Llibrary, Office, Home}. 
Abstraction in granularity is achieved when the proposition 
Above (Book, Table ,s) is translated into Above (Book, Table) 
given the context (s). 

Abstraction is also a task that is automated by wrappers. 
Text clustering is a currently used as an abstraction technique 
where distances (arbitrary metrics) to a given database of col- 
lection of key terms (i.e. contexts) are computed [9]. Either 
way expertise is required in writing the axioms or formulating 
the wrapper itself. q 

Context: Context has been proposed as a means of defin- 
ing the validity of a sentence relative to a situation. For- 
malizing contexts [31][24][11] allow predicates for fixed situ- 
ations to be “lifted” to more dynamic contexts where situa- 
tions change. The context formalism is an extension to first- 
order logic in which- sentences are valid within a context. To 
this end, we use the denotation of ist(c;p) such that we 
have a formula of a proposition p which is true in a con- 
text c. For example given a context Office, one can write 
ist (Office; Above (Book, Table)), In this paper we drop 
ist and consider a concise and simple form as in the formulas 
(c; p). From the previous example we may write the proposition 
(Office; Above (Book, Table) ). In the implementation of the 
latter example, the mediator was programmed with a pattern 
matching template of the form (AXIOM: 123 (CONTEXT Office) 
(RELATION Above) (OBJECT Book, Table)). 

At this point it is worth noting a difference between the con- 
text logic formalism approach and the one in this paper which is 
that context logic defines a default coreference rule which states, 
that as a default, the meaning of a symbol does not change from 
one context to another. We consider that symbols never mean 
the same. The key in resolving ambiguity of meanings of a term 
is in observing the corresponding contexts. 

Hence, for the interface example above for the context 
Factory for the bicycle components, one can write 

ist(Factory; Spoke(x) A Vheel(y) A Frame(z)). 

□ 

Articulation Rules: The term articulation axioms has been 
established in [24] but refers to the rules that axe used for trans- 
lating concepts across domains. In this paper we refer to these 
rules as the articulation rules. For instance, when the bicycle 
components of a Factory match the concept of Bicycle in a 
Shop. Hence one can write 

ist (Factory; Spoke(x) A Wheel(y) A France (z)) 
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ist(Shop; Bicycle(z)) 

The articulation rules and their specification are the compo- 
nents of the domain algebra which describes the linkages that 
handle interoperation between the independent systems. The 
articulations allow equivalence from server-to-server and the 
interactions between heterogeneous objects distributed over a 
wide-area network. O 

Partitioning: In a certain application, there is an interest in 
certain Articulation Rules rather than the complete intersection 
of the domain. Partitioning is equivalent to the production of 
subsets of the articulation rules. When involving multiple or 
large domains, partitioning is the process of selecting, combin- 
ing, extending, and specializing sets of articulations. For exam- 
ple a domain could be abstracted automatically in one partition 
whereas an expert assertions on the domain are maintained in 
another. For instance, a domain expert of a Factory and Shop 
models can group 

Partition(SEASONAL MARKET) : 

ist(Factory; Spoke(x) A Wheel(y) A Frane(z)) 

<=> 

ist(Shop; Bicycle(z)) 

Where the partition SEASONAL MARKET specializes an articu- 
lation rule. □ 

IV. A Domain Algebra 

Automatic reasoning about the interfaces requires a formal 
approach to the transformation and manipulation of the artic- 
ulation rules. Hence a set of operations are established for the 
needed manipulations. These operations describe the domain 
algebra. 

The domain algebra is symbolically composed of two types, 
namely partitions, articulation rules and operation symbols. 
The articulation rules are atomic elements of the partitions. The 
Partitions and articulation rules themselves are the elements of 
the algebra. On the other hand, the symbols of operations, such 
as p|, (J and — , stand for the algebra operations. For multiple 
domain sources, the complete operations among domains are: 


Operation 

Symbol 

Semantics 

Intersection 




Create sharable expressions 

Union 




Create all expressions 

Difference 

- 

Create not shared expressions 


• Intersection: The intersection is the first concept of the 

domain algebra since it allows the algebra to bring together 
two domains. It is equivalent to an AND operator. The 
concept of intersection is not exactly like the predecessor 
algebras: the intersection is hand-crafted and reflects the 
articulation rules. 

• Union: The union concept allows the algebra to bring to- 
gether two domains to form a new one. It is equivalent to 
an OR operator. However the algebra lacks a formal ap- 
proach to eliminate redundant knowledge that is common 
to both. This leads to several ways of establishing the 
unions of multiple domains. It is convenient to think of 
knowledge as not being redundant if not explicitly speci- 
fied by the articulation rules. Similarly to the natural join 
in relational databases, the domain algebra union joins in- 
terfaces when they link through shared articulation rules. 
The union is restricted only to the knowledge that the rules 


relate to. In object oriented models, inheritance and class 
ownership are typical relations that an articulation rule 
can relate to. 

• Difference: The difference concept completes the algebra 
and its presence compensates for the absence of negation 
[46]. The difference operation retrieves the elements in 
domains that are NOT covered by another. Hence, the dif- 
ference operation results in asymmetrical results and is not 
commutative. 

Such an algebra can provide a basis of interrogating multiple 
interfaces which are semantically disjoint, but where a shared 
knowledge base has been established. 

V. Surrogates: Knowledge Formulation AxNd 
Rewriting 

The previous sections defined a few requirements of the me- 
diated architecture. However, these requirements place no re- 
strictions on the possible context entailment propositions can 
have. In this section, we explore the effect of the partitioning 
against the effect the domain context for semantic distinctions. 

In this section we also explore the implication of the mediated 
architecture on using the domain knowledge. We assume that 
the underlying knowledge has been compiled into declarative 
languages which correctly conceptualized the domain knowledge 
as propositions. The mediator addresses several tasks in using 
the domain knowledge, namely resolving implementation differ- 
ences, interpretation and partial information. 

1. Resolving composition differences : As some of the work 
on designing interfaces focuses on designing data models, 
one can realize the different possibilities for modeling con- 
cepts. For an interoperability problem such as in data inte- 
gration process, one should focus on relating the difference 
among data models, e.g., mapping the relational model to 
the object model which requires structural knowledge [44]. 
However, even if we consider for example only databases 
using the same data model, there are significant differences 
which make the task of relating the semantics of the data 
model difficult. These differences are due to their schema 
composition. 

2. Interpretation: To permit the explicit knowledge as in the 
case of databases to interoperate with other sources, it is 
not sufficient to simply use the information on the basis 
of vocabulary used in the domain. The vocabulary used 
does not correspond to intended meanings. For instance 
terms like Id, SSN etc. should map to Identification, 
Social Security Number respectively. For each of these 
domain schemas, their corresponding knowledge is exam- 
ined in parsing their vocabulary and the specification of 
their relationships, new surrogated (aliases) terms can be 
used. Interoperability can occur in a sound manner with 
propositions. 

3. Partial information: To handle partial information ex- 
tracted from declarative interfaces. This problem in 
database interoperability is simply typified by the symp- 
toms of most directed graphs which is their inability to 
handle partial information [20]. For example it is very dif- 
ficult to assert a proposition in a object hierarchy without 
a reference to a root object. The lack of reference in gen- 
eral is often found with systems that lack external schemas. 
Similar partial information populates most semistructured 
information systems, e.g., the World Wide Web. 
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A. Knowledge Formulation and Rewriting 

Our interest is in expressing articulation rules in the frame- 
work of propositional calculus. This interest is based on a com- 
bination of two features of the mediated architecture. First the 
knowledge needed can be expressed in a form more or less in- 
dependent of the uses to which the knowledge might be part of 
Second the reasoning performed by the partitioning process in- 
volves basic but simple logical operations on these propositions. 

In the implementation of the mediator, we specify the propo- 
sition rewriting within first-order logic and use the formalism to 
constrain the propositions in terms of their context. A context 
can be thought of as a set of terms labeling a set of propositions. 
Intuitively, we assume a context production rule which states 
that the meaning of a proposition admits the context defined 
by the symbols stated within the proposition. For example, 
the proposition Above (Book, Table) has as possible contexts 
Book and Table. Although the definition of the context produc- 
tion rule is not very suggestive, it is not the case when consid- 
ered within the framework of propositional calculus and context 
logic. In general, we consider the formulas as propositions of the 
form 

(ci, ..., ;pi, (1) 

which are to be taken that the propositions pi } axe true in 

the contexts ci, For example, if we consider the propo- 

sition (Office, Book; Above(x, Table)), then we know that 
predicates Above (x, Table) is true in the context of Office 
and Book. The aim of reformulation context is not to use de- 
duction as the computational framework, but rather to integrate 
knowledge into optimal articulation rules when the interopera- 
tion objectives are clear. 

One can become concerned with the number of possible 
propositions that can be calculated from Equation 1. We sim- 
plify the problem by focusing only on the articulation needed 
for interoperation. Since automated inferences axe potentially 
capable of processing the symbolic propositions, the need for 
rules about how to process the knowledge becomes essential. 
Although there are no general rules in establishing the rewrit- 
ing of the propositions, the mediated architecture supports the 
two performative rules: spanning context and specializing. Both 
reduce the scope of the interoperation. 

1. Spanning Context: by providing a proposition with con- 
text such as considering the conjunction of the propo- 
sition (Database ; isa(x, Table)) to (Object; isa(x. 
Table) ) from the example stated in previous section and 
having (Database, Object; isa(x, Table)). Formally 
we have 

( C UP) A (c 2 ;p) <$=> (ci, c 2 ;p) 

2. Specializing: by providing a context with propositions such 
as 

providing the proposition (Object; isa(x, Furniture)) 
to the proposition (Object; isa (x , Table ) ) and having 
(Object; isa (x, Furniture) , isa(x , Table) ) . Formally 
we have 

(c;pi) A (c;p 2 ) ^ (c;pi,p 2 ) 

Since we deal with propositions, the rules of first order and 
context logic apply. When the number of propositions is zero 
(N = 0 in Equation 1), then the vocabulary has its own context. 

For instance we have the list {Office, Table, Book}. 

Another important possibility when rewriting the knowledge 
is that propositions are always asserted within other predicates 
in a recursive form. Henceforth given the general denotation of 
Equation 1, we have recursively (c i; ( Cj ; .), .) and subsequently 
(Object; (Furniture; isa(x, Table) )) . 


In general, the achievement in recursively rewriting the con- 
text and propositions deals directly with the critical and dif- 
ficult step in context abstraction and is also a contribution of 
this paper. Although the problem of interoperating with re- 
cursive definitions is difficult to achieve with minimal inferenc- 
ing, rewriting the context recursively has two advantages, (i) 
it maintains the connectivity of the knowledge and (ii) it pro- 
vides one way to control the context abstraction. The latter 
is achieved by asserting one context for each predicate. The 
current implementation does not support recursive definition. 

Another potential interest in recursive rewriting is that it 
converges to the Object Extended Model (OEM) formalism 
which has been widely used, namely as the intedin™ 0 ti»o 
S tanford-IBM Manager of Multiple Information Sources (TSIM- 
MIS) [50]. OEM is a self describing object model with nested 
identity. Every object in OEM consist of an identifier and a 
value. The value is either atomic, or set of objects, denoted 
as set of {label, id, value}. We refer to the label and value as 
context and predicate respectively. 

It should be noted that one of the innovations of the medi- 
ated architecture is that the proposed articulations need not 
be static. The partitioning of the domain knowledge is dy- 
namic where articulation rules are asserted and retracted inde- 
pendently of the underlying knowledge base. 

VI. Implementation: “Server-to-Server” 

This section provides an overview of one implementation of 
the system capable of operating over the knowledge described by 
registered interfaces in CORBA interface repositories. The sys- 
tem is based on interfacing CORBA, HTML/XML type servers 
since XML is most likely to become the next industry stan- 
dard for Internet client-server and distributed systems. The 
current generation of the system interoperates for Internet and 
HTML/XML (extensible Markup Language) servers, there is 
preference to present in this paper the complete original proto- 
type which was written for CORBA applications only. 

The Mediator” software component that incorporates the 
domain algebra and articulations is a First Order Logic Pro- 
duction System. To allow a long-range vision and yet a fast 
development to market, off-the-shelf components were selected 
and hence the system was brought to meet numerous objec- 
tives. One of the objectives is to build an extendible proto- 
type? a system that cam supports non-traditional applications 
and can serve as a environment for future innovations (e.g. 
when HTML/XML component was added on) and other im- 
provements to enhance the information integration technology. 

A. CORBA: A Brief Overview 

The CORBA is a system of standards and specifications that 
describes how software components can interoperate across net- 
works, languages and platforms [32]. CORBA allows for client- 
server interaction between heterogeneous objects distributed 
over a wide-area network. CORBA makes meta information 
describing the objects in a system and their interfaces available 
so that it can access other objects. Any object connected to 
an object Request Broker (ORB) can play simultaneously the 
role of client and server and hence Objects can initiate calls 
and respond to requests. ORB is the part of CORBA which 
facilitates client-server communication and interaction between 
distributed objects. 

To reach object interoperability and for objects to plug and 
play, clients have to know exactly what they can expect from 

5 Currently Science Gate map genomic databases to diseases. 
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every object they might call upon for a service. In CORBA, 
the services that an object provides are described to interface 
between the object itself and the rest of the system. The ob- 
jective of the interface is twofold: (i) it informs clients of the 
services that the objects provide as well as the access method 
to invoke these services and (ii) it informs the communications 
infrastructure of the format of the access methods. 


calls to the Interfaces Repository. Moreover, this function will 
then define all the interfaces locally. Although all the attributes 
and operations of the remote objects will also be put into the 
definition of the local objects, they are not used to store or re- 
trieve values at this point. For instance, one may interrogate 
interfaces for their corresponding contents, given a Factory do- 
main locates at IP address 171.64.75.95, 


B. The Mediator 


(defcontext FACTORY) 

(GetCorbalnterf ace * f 171 . 64 . 75 . 95 * J ) 


The mediator was built using a productive development and 
delivery expert system tool which provides a complete environ- 
ment for the construction of rules, knowledge and objects [40]. 

The nicuiauOi piOvidcS <a ^uIlcSavc AnC wieuge xcpx cSciitiiuiuu 

tool for handling a variety of knowledge with support for three 
different programming paradigms: rule-based, object-oriented 
and procedural. The rule-based, are primarily intended for 
heuristic knowledge based on experience and hence articula- 
tion rules. On the other hand, the object-oriented program- 
ming allows complex systems to be modeled as modular com- 
ponents. The five generally accepted features of object oriented 
programming are class definitions, message handlers, abstrac- 
tion, encapsulation, and inheritance. The object representation 
will be used to mirror hierarchically the declarative interfaces 
with object oriented flavor. The rules can interact and match 
objects. The procedural programming capabilities provide the 
necessary degree of freedom to expand for additional program- 
ming power. The system has Lisp like syntax to correspond to 
the First Order Logic. 

The mediator includes a number of features to support the 
verification and validation of articulation rules, including sup- 
port for modular design and partitioning of articulation rules, 
static and dynamic constraint checking of values and function 
arguments, and semantic analysis of rule patterns to determine 
if inconsistencies could prevent a rule interaction with the ob- 
jects. 

The mediator is based on B-trees indexes and a fast Rete 
pattern matching algorithm inherented from [40]. The efficiency 
of this algorithm is based on the assumption that data changes 
slowly over time. This assumption matches perfectly the nature 
of declarative interfaces that also slowly change over time. 


and a Shop domain at an IP address 171 .64.75. 15, 
(defcontext SHOP) 

(GetCorbalnterf ace ‘ ‘ 171 . 64 . 75 . 15 J * ) 


Browsing the corresponding surrogates, we have 


DOMAIN FACTORY 


DOMAIN SHOP 

FACTORY 


SHOP 

FRAME 


BICYCLE 

Dimension 


Size 

Color-table 


Color 

SPOKE 


stock-number () 

WHEEL 


SUPPLIER j 


After GetCorbalnterf ace acquires the interfaces from the In- 
terface Repository of the CORBA server and maps them locally, 
the system is ready to interoperate and create objects of the in- 
terfaces. More than one object of the same class can be created 
and each of them actually has its own context. The defcontext 
specification is equivalent to a module definition. 

To keep track of all the references to CORBA objects created 
that were dynamically created, each local object references back 
the actual CORBA object to be able to retrieve attributes and 
invoke operations. This also maintains the independency and 
evolution of the servers. Hence a new attribute in every local 
object that corresponds to a remote CORBA object is created. 
This attribute is called CorbaObjectNum, which is a mapping 
between a local object and a remote object. 


MakeCorbalnstance 


interface- name object-name 


This function is needed for making instances of CORBA ob- 


(7. The Dynamic Invocation Interface Functions 

The Dynamic Invocation Interface (DII) allows requests to 
be built up and invoked dynamically to CORBA servers. Ini- 
tially, clients need to know interface-related information only 
at the invocation time. A DII request, like a static request, 
is composed of an operation name, an object reference, and a 
parameter list. 

In the current implementation, three functions were inte- 
grated in the system to support the DII requests. The objective 
is that given an object reference, the object’s type and all in- 
formation about that type can be determined at runtime by 
calling functions defined by the Interface Repository. In par- 
ticular, these functions can determine: the module in which 
the interface was defined, if any, the name of the interface, the 
interface’s attributes and their definitions, the interface’s oper- 
ations and their definitions, including parameter, context and 
exception definitions, and the inheritance specification of the 
interface. 


Get Corb alnterface 


server-name 


This function is to get all the interfaces from the Interface 
Repository of a CORBA server, whose name is the parameter 
of this function. It will get the necessary information through 


jects, and the new information is stored in the local objects. 
This information is called CorbaObjectNum and provides the 
mapping between the mediator objects and CORBA object ref- 
erences on the server. The full interface description will be put 
in a string, which is also stored as an attribute. This function 
takes two parameters: the class name and the object name. For 
instance one may interrogate the class BICYCLE in context SHOP, 
or more precisely SHOP: : BICYCLE as 


(MakeCorbalnstance SHOP :: BICYCLE [Bontrager] ) 

and hence a local surrogate object [Bontrager] is created. 
Each MakeCorbalnstance request updates the object references 
through CorbaObjectNum. 


J InvokeCorbaOperations 
turn 


CorbaObjectNum operation re- 


This function makes remote function calls to the objects re- 
siding on the CORBA server. It takes in the CorbaObjectNum, 
which provides the mapping between local mediator objects and 
remote CORBA object references on the server; the name of 
the operation that the user wants to invoke, and finally a multi- 
field value. This multi-field contains first the return type; then 
if the return is OBJREF, the return new object instance name 
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and class name; and finally a list of type/value pairs of parame- 
ters. Types can be OBJREF , SHORT, LONG, USHORT, ULONG, FLOAT 
DOUBLE, BOOLEAN, CHAR, or STRING. InvokeCorbaOperations func- 
tion calls the necessary CORBA functions to perform the op- 
eration dynamically. For instance, one may invoke a CORBA 
operation 

(InvokeCorbaOperations 

(send [Bontrager] get-CorbaObjectNum) 

"get - st o ck-number " 

(FLOAT) ) . 

The specific operation 

vsena Looatragerj get-Corbaub j ectmim) 


The is -a constraint is native to object-oriented relations and 
is used for specifying class constraints. This constraint also 
encompasses subclasses of the matching classes. On the other 
hand, the :* symbol is a new notation and is a predicate return 
value constraint operator. When needed, it is possible to use 
the return value of the external function map to modify the 
value of a field. In the conversion of an articulation rule to 
production rules, the predicate return value constraint operator 
is translated in the action list. 

Redefining a currently existing articulation rule causes the 
previous rule with the same name to be removed. 

I 1 articulation-name 


gets the index into the CORBA object array to get the ob- 
ject reference. "Get-stock-number" is the desired operation to 
invoke on the object. In this example, stock-number computes 
the amount of items in stock. The multi-field (FLOAT) stores the 
information of the return type of the operation and information 
about the parameters, in this case a float value. 

D. Articulation Rules: Bi-directional production Rules 

A production rule facility allows definitions of operations that 
are executed whenever specific events occur or certain condi- 
tions are met. In general, a production rule takes the form of: 

If [ condition } then [ action } 

The approach taken by the production rules community has 
been to provide rules that take the activity in one direction, 
namely Left Hand Side (LHS) where conditions and patterns 
are described to the Right Hand Side (RHS) where the corre- 
sponding actions are listed [6]. On the other hand, articulations 
are equivalence rules and a new mechanism was adopted to ref- 
erence them. In general, an articulation rule takes the form 
of: 


The delete- articulation removes a previously defined articu- 
lation rule. Since an articulation is effectively two production 
rules, the deletion of an articulation rule is equivalent to the 
deletion of two production rules. The previously created rule 
new-rule can be deleted as 

(delete-articulation new-rule) 


modify-articulation 
tion ~~ 


articulation-name partition bb parti - 


The modify-articulation action allows the partitions of artic- 
ulation rules to be modified. The partitions of an articulation 
rules can be changed after the rule has been defined. How- 
ever, this requirement is not enforced since the modify action is 
actually a deletion followed by the new definition. The modify- 
articulation is meant to complete the set of defining and manip- 
ulating the articulation rules. 

(modify-articulation new-rule 

(object (is-a FACTORY: : FRAME | DEPOT: : FRAME) 

^ ^(Dimension ?x)) 

(object (is-a SHOP: :BICYCLE) 

(Height ?x) ) ) 


[condition- action] equivalent [condition- action] 

The syntax of the writing of articulation rules is based on an 
extension of production rule construction. An articulation rule 
is parsed in two directions and hence it becomes equivalent to 
two production rules. The current implementation of the articu- 
lation rule system includes three commands for defining and ma- 
nipulating rules, namely define- articulation, delete- articulation 
and modify-articulation. 

A production rule is activated when the condition is matched 
and the actions are executed. On the other hand, the actions 
modify the working memory according to the rule specifications. 
Since the mediator lookup is purely pattern- based, the trigger- 
ing events are directly linked to the objects manipulated with 
the Dynamic Invocation Interface Functions, namely GetCor- 
balnterface , MakeCorbalnstance and InvokeCorbaOperations. 


The “l” constraint is a connective constraint. The medi- 
ator syntax allow three connective constraints, namely 1 * Sc * * 
(and), | } 5 i^or; and 1 1 J * (not). The 1 1 k } 1 constrains is sat- 
isfied if two adjoining constrains are satisfied. The ' * | > » con- 
straint is satisfied if either of the two adjoining constrained are 
satisfied. The ’ constraint is satisfied if the following con- 
straint is not satisfied (Further details on predicate connective 
constraint and other features can be found in the the technical 
overview guide). 

The two examples introduced in the define- articulation and 
modify-articulation cases demonstrate the mechanism of relat- 
ing partitions. Since a partition may include more that one con- 
dition, conjunctive conditions can be listed with no constraint 
operator. The reason of listing two partitions with different con- 
texts in the articulation rule as in the modify action examples 
demonstrate the multiple inheritance capability. 


I define-articulation 
tion 


articulation-name 


partition parti- 


define- articulation is a mediator function that creates rules 
construct. This function effectively creates two production 
rules. For instance, a new rule, namely new-rule, can be defined 
as 

(define -articulation new-rule 
(object (is-a FACTORY: .-FRAME) 

(Dimension ?x := (map ?x "10 01-04;.."))) 

(object (is-a SHOP :: BICYCLE) 

(Size ?x := (map ?x "01-04 10;..")))) 


E. Operating over Domains 

This section illustrates three examples of the domain ontol- 
ogy algebra relating to three operations, namely intersection, 
union and difference. The articulation rule examples introduced 
in Section VI-D can be alternatively edited in a user interface 
through tables. The intersection, union and difference exam- 
ples in the current section refers to the set of articulation rules 
described in Table VT-E. Reading Figure VI-E from right to 
left, the articulation rules column displays the rule number. An 
interface name and class name are possible contexts for an en- 
try. The predication occurs at the attribute level. Mapping 
functions are expanded to their contents. 
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1. Domains intersection: A FACTORY can query the domain 
SHOP and acquire the number of BICYCLE sorted by color 
and amount in stock. 

2. Domains union: A consulting agency can verify for the do- 
main FACTORY and acquire the number of BICYCLE, sorted 
by color and amount in stock, for more than one shop. 
This reflects a union over multiple domain intersections. 

3. Domain differences: A FACTORY can query the domain 
SHOP and acquire the components or accessories that the 
SHOP relates to the BICYCLE, but FACTORY does not manu- 
facture. 

While intersection of multiple domain is comparably small to 
the domain themselves, placing the articulation rules in main 
memory is viable way to gain performance and thereby make 
it suitable for real time applications. These applications are 
envisages to interoperate with hundreds of domains. 

VII. Status, Conclusions and Future Work 

The current implementation is currently written in C/C-F+ 
ans integrates the C Language Integrated Production System 
[2 2] [40]. Since user interface functions and data access functions 
are separated out into other components, the domain algebra 
consists mainly of rules. 

The system as described in this paper is fully implemented 
and operational in Internet applications. The CORBA plu- 
gin component consists approximately of 4.000 lines of C/C-f-f- 
code. The actual coding took about three raan-months, but the 
system was carefully designed before any implementation be- 
gan. The full blown mediator system exceeds the 150,000 lines 
of C/C+ff code. 

The fact that the system could be implemented in a short 
time reflects well on the integration aspects. This also under- 
lines the intent of the author of system integration as opposed 
to coding. One intention of the implementation is that it can 
be used by researchers not involved in establishing domain alge- 
bras. The wrapper that translates CORBA interfaces to the me- 
diator is currently made available as a public software package 
and can be down-loaded from (vvw-db. Stanford. edu/'maliif/- 
ccnp/c cnp.html). The orginal CORBA wrapper was written 
jointly with Marcus Chan at Stanford University, To this stage 
the software has been down-loaded to over 100 researchers or 
users across the Internet. 

This paper presents an approach that uses context formalism 
in the development of standard knowledge representations and 
knowledge sharing and plays a role in knowledge interoperabil- 
ity. The context approach provides a powerful tool to define the 
validity of knowledge relative to a situation. This paper address 
the problem of how to abstract and entail encoded knowledge 
within contexts. 

We describe an environment to interface underlying knowl- 
edge resources to the outside world. The objectives set in this 
paper are to establish the intermediate model needed to sustain 
interoperability and to produce the needed environment. Hence, 
users and system developers can translate knowledge bases that 
provide comprehensive but simple coverage of topics of interest, 
knowledge usability and re-usability by different applications 
and knowledge maintenance in rapidly changing environments. 
The mediator can bring about a shift from merging knowledge 
to the manipulation, enhancement, and maintenance of domain 
intersections. The main objective of the mediator will be to 
handle an algebra that combines and partitions structures in a 
sound and well-behaved manner. 

This paper describes a system of allowing multiple declarative 
interface interactions between heterogeneous objects distributed 


over a wide-area network. The objectives set in this paper axe 
to establish the articulation needed for a domain algebra and 
thus sustain interoperation. 
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